I'm aware of the test failures and will fix them soon.

CLI PR: dandi/dandi-cli#1288

@jwodder was proactive and prepared a PR for the change in API return values, but I wonder if such change is really needed? Ideally API (or ABI as the schema of returned structures) should not change without a significant reason since it would break prior versions of client(s) etc.
@AlmightyYakob would you be so kind to provide a summary of the change in returned data structure and why it cannot be avoided.

@AlmightyYakob would you be so kind to provide a summary of the change in returned data structure and why it cannot be avoided.

Previously for asset validation errors, the API returned a flat list of errors (dicts), with no distinction as to which errors belonged to which assets. Since each asset can have more than one error, the format of dict[str, list[dict]] seemed the most efficient way to convey this.

@AlmightyYakob would you be so kind to provide a summary of the change in returned data structure and why it cannot be avoided.

Previously for asset validation errors, the API returned a flat list of errors (dicts), with no distinction as to which errors belonged to which assets. Since each asset can have more than one error, the format of dict[str, list[dict]] seemed the most efficient way to convey this.

ATM it does feel like that indeed. But in the long run, it might be "too restrictive": an error might relate to multiple assets, or to some entity over assets ("sub-X/ folder is not listed among participants.tsv" in BIDS), etc. Why not to just add path field and keep otherwise returning a list?
If it is desired for a viewer to group by path, it would remain a trivial operation, and could have any flexibility desired. FWIW, it would also relate nicely to our ValidationResult records which we might want to group by path or by error id or by some other criteria.

@AlmightyYakob would you be so kind to provide a summary of the change in returned data structure and why it cannot be avoided.

Previously for asset validation errors, the API returned a flat list of errors (dicts), with no distinction as to which errors belonged to which assets. Since each asset can have more than one error, the format of dict[str, list[dict]] seemed the most efficient way to convey this.

ATM it does feel like that indeed. But in the long run, it might be "too restrictive": an error might relate to multiple assets, or to some entity over assets ("sub-X/ folder is not listed among participants.tsv" in BIDS), etc. Why not to just add path field and keep otherwise returning a list? If it is desired for a viewer to group by path, it would remain a trivial operation, and could have any flexibility desired. FWIW, it would also relate nicely to our ValidationResult records which we might want to group by path or by error id or by some other criteria.

In the interest of reducing the blast radius from the changes we're making to support better validation error UX, we'll maintain a flat list structure, adding a path property. This will likely allow for closing dandi/dandi-cli#1288 while allowing the UI to add incremental value.

Your other arguments about restrictiveness point to a different issue, that it is becoming more and more difficult to mediate both the CLI's and web app's needs through a single public API. I have a bold idea here, but I need to think about it a bit more before I share my thoughts (perhaps in a design doc). Stay tuned.

Your other arguments about restrictiveness point to a different issue, that it is becoming more and more difficult to mediate both the CLI's and web app's needs through a single public API. I have a bold idea here, but I need to think about it a bit more before I share my thoughts (perhaps in a design doc).

I would like to hear some of such issues first before we even contemplate a possible redesigns etc. IMHO the proposed here idea of changing the Model (if we think in terms of MVC design pattern) was not really needed/desired regardless either it is for Web or CLI.

ping: conflicts

@mvandenburgh @marySalvi This PR is ready for review.

@AlmightyYakob Please summarize the changes to the API that this PR currently makes.

@AlmightyYakob Please summarize the changes to the API that this PR currently makes.

The only API change is that now the objects in the asset_validation_errors list include an extra path field, which represents the path of the asset that the error belongs to.

🚀 PR was released in v0.3.42 🚀